In a traditional non-threaded environment, applications follow a single thread of execution. This results in synchronous behavior. For example, in a messaging context, an application needs to obtain information from a database. The thread of execution begins with the client application determining a request is needed and generating the request. The thread then follows the request to the destination database (or destination application). The destination application processes the request and sends a reply to the client application. The client application receives the reply to its request and again takes up the thread of execution and moves forward. The client application is frozen, taking no action, from the time the request is sent until a reply is received. This defines traditional synchronous behavior.
More modern operating systems provide multi-threaded environments which facilitate asynchronous behavior. In a multi-threaded environment, the same client application has the option to obtain information sychronously or asynchronously. Synchronous behavior would follow the same path as the single-threaded example described above. To obtain information asynchronously, the client application would invoke an additional thread supported by the operating system and commence the search on that thread, while continuing to move forward on the main thread of execution during the pendency of the search. Once the results had been obtained, the search thread (monitored and maintained by the operating system) would return and notify the client application on the main thread of execution that results were available and provide those results on request of the client application, and subsequently dissipate the thread. The notification and provision of results would occur through hooks and commands built into the same portion of the operating system which manages, tracks, and maintains the multiple threads. By using resources from the operating system, applications can start multiple synchronous calls. For operating systems that support threads, a better solution is to use threads. For operating systems that do not support threads, the alternative is to start new processes, but that is very expensive in programming and CPU overhead for each application to manage a group of separate processes.
One example of a service and event manager taking advantage of a threaded environment is U.S. Pat. No. 6,012,081 issued to Dorn et al, which is incorporated herein by reference. In this and other examples, systems use a thread-supporting environment to support both synchronous and asynchronous messaging and retrieval. To contrast it in another way, the request/response paradigm used in client/server and distributed object systems is an inherently synchronous connection. A client application requests a service from a server. While the server is processing the request, the client waits for the response and is blocked from doing any other work. But client/server and distributed object systems can support asynchronous requests using threads. To execute a request asynchronously, the client application creates a “request” thread and executes the request from within the thread. The request thread remains blocked while the server processes the request, but the main client thread can continue to process other tasks. Multiple threads can be used to process multiple requests concurrently.